chore: Test of connection rest between routing #4355
Conversation
github-project-automation
bot
moved this to New
in API Mediation Layer Backlog Management
…ying POST - reactor.netty.http.client.PrematureCloseException) Signed-off-by: Pavel Jareš <Pavel.Jares@broadcom.com>
EvaJavornicka
moved this from New
to In Progress
in API Mediation Layer Backlog Management
| void givenConnectionInPool_whenServerWasRestarted_thenRetry(String method, MockService.ConnectionCleanupType cleanupType, int responseStatus) { | ||
| var port = mockService.getPort(); | ||
|
|
||
| given() | ||
| .header(HEADER_X_FORWARD_TO, "serviceid1") | ||
| .when() | ||
| .get(basePath + "/200") | ||
| .then() | ||
| .statusCode(is(SC_OK)); | ||
|
|
||
| mockService.cleanConnections(cleanupType); | ||
|
|
||
| var port2 = mockService.getPort(); | ||
| assertEquals(port, port2); | ||
|
|
||
| given() | ||
| .header(HEADER_X_FORWARD_TO, "serviceid1") | ||
| .when() | ||
| .request(method, basePath + "/200") | ||
| .then() | ||
| .statusCode(is(responseStatus)); | ||
| } |
There was a problem hiding this comment.
I'm not sure I understand what the purpose of this test is, what happens if you try to send the request before cleaning up? Would that make the purpose more clear?
There was a problem hiding this comment.
I don't think so. The first request is to warn up. It means the pool on both services side is established. The clean-up close connection on one side (the type simulate a specific operation) and the second call verify the handling of closed connection. We can make as many request we want before. It cannot change the behaviour after clean up. And the issue is related to the first call after clean-up.
There was a problem hiding this comment.
I'm just wondering what does it take to break this test, that's the part that's not very clear for me. Or which part of the API ML does not work otherwise, it feels to me that it's testing the mock service rather, but if it's clear to you it's fine with me.
There was a problem hiding this comment.
It is testing the retry logic and handling connection in the outbound calls (see HTTP client in the gateway), If there is a change in handling I/O exceptions of prepared connection or retry logic it could break the test.
Description
This PR add a test that simulate one known issue about communication to the service. When communication is broken it stop sending a request and an exception is thrown.
The point is that GET request could be retried (GET means no change on remote side), but for POST it depends on the state. If request was sent (at least from application point of view) we cannot retry it, because it could be effective done twice. We can potentially retry other method than GET only if the error happened before sending the data.
This test could be helpfull in case of replacing HTTP client or for reproducing a similar issue. It definetelly cover these edge cases and define current state.
Linked to # (issue)
Part of the # (epic)
Type of change
Please delete options that are not relevant.
Checklist:
For more details about how should the code look like read the Contributing guideline